• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    POLICIES FOR DOWNLOADING CONTENT AND UPLOADING CONTENT. Methods and arrangements for defining a policy for downloading media content from IPTV from a Content Server (5) to User Equipment (1), and / or for uploading media content from a User to a Content Server. The policy is typically a bandwidth reservation, and the type of download / upload of Content will be included in an initial request from the User Equipment, for example, in an SDP Offer, sent to a control node IPTV (4).
    公开号:BR112012013927B1
    申请号:R112012013927-4
    申请日:2010-11-30
    公开日:2021-02-02
    发明作者:Jan Erik Lindquist；Mats Cedervall
    申请人:Telefonaktiebolaget Lm Ericsson ( Publ)；
    IPC主号:
    专利说明:

    TECHNICAL FIELD
    The present invention relates to methods for a User Equipment and for an IPTV control node to upload / download IPTV media content to or from a Media Content Server, as well as to a User Equipment and an IPTV control node. FUNDAMENTALS
    An end user can access IPTV (Internet Protocol Television) services from services of different types of UEs (User Equipment), such as, for example, a TV, a PC (Personal Computer) or a cell phone, for example, through the IMS (Internet Protocol Multimedia Subsystem), as long as the UE has adequate functionality, which can be specified, for example, according to the specification of the Open IPTV Forum.
    Conventionally, bandwidth can be reserved when setting up a session, such as, for example, a Video on Demand session, which is using a unidifusion stream, or a conventional television broadcast session, which is using a multicast flow. Bandwidth reservation
    Will ensure that there is sufficient bandwidth, both in the "last mile" for the subscriber and in the aggregation network, in order to provide the user with an adequate experience without any interruptions or disturbances in the service. In addition, two sessions can together exceed the available bandwidth in the last mile. This will cause packages in both sessions to compete with each other, and results in some packages being dropped in both sessions. Thus, it is important that a new session is not allowed to affect existing sessions, since bandwidth has been reserved for existing sessions.
    Media Content Can Be Downloaded From A Media Content Server To An Eu, Acting Like A Client Terminal, For example, By Progressive Downloading, 30 In Which Media Content Is Stored In A Local Buffer In order To Allow Playback Of The Media File Before The Download Is Completed, By Streaming Streaming, Where Media Content Is Streamed From The Content Server At The Playback Rate, And Involving No Storage, Or By Streaming Streaming Adaptive, where content can be downloaded at different bit rates. Similarly, media content can be uploaded from a eu to a content server, and can subsequently be shared with other users using download.
    However, a conventional HTTP progressive download of media content only supports a best effort Quality of Service, that is, no guaranteed QoS, and the bandwidth may not be the maximum bandwidth. Consequently, in the event that the resolution of the media content is high and the network has limited bandwidth, the user experience of playback may be poor. For example, media content downloaded from the well-known YouTube website is displayed while it is being downloaded, using only Quality of Service best effort. If the resolution is limited and not too high, the available bandwidth may be sufficient, and the user experience of the media content being played acceptable. However, otherwise, the user experience may be poor.
    In addition, a correct reproduction of a downloaded media file 10 progressively requires that the UE, that is, the client terminal, is capable of buffering a large amount of media content.
    As such, it still presents a problem in reaching an acceptable level of user experience for media content being played. SUMMARY
    It is an objective of modalities described below to address at least some of the problems described above, and this objective and others are achieved by the method and the apparatus, according to the attached independent claims, and by the modalities, according to the dependent claims.
    Modalities according to a first aspect provide a method for a 2 0 User Equipment to define a policy for downloading IPTV content from a Content Server, or a policy for uploading IPTV content to a Content Server. Contents. The User Equipment generates a request that comprises an indication of the type of content download or content upload, and transmits the request to an IPTV control node.
    Modalities according to a second aspect provide a method for an IPTV control node to configure a policy to download IPTV content from a Content Server to a User Equipment, or upload IPTV content to a Content Server from User Equipment. The IPTV control node receives a request from the IPTV equipment.
    User, the request comprising an indication of the type of content download or content upload.
    Modalities, according to a third aspect, provide User Equipment, willing to create a policy to download IPTV content from a Content Server, and / or to upload IPTV content to a 35 IP Server. Contents. The User Equipment comprises a communication device provided with processing circuits, and is configured to generate a request, comprising an indication of the type of content download and / or content upload, and transmit the request to an IPTV control node. .
    Modalities, according to a fourth aspect, provide an IPTV control node, willing to define a policy to download IPTV content from a Content Server to a User Equipment, and / or to upload content for IPTV to a Content Server from User Equipment. The IPTC control node comprises a communication device, provided with processing circuits, and is configured to receive a request from the User Equipment, and the request comprises an indication of the type of content download and / or content upload .
    An advantage with exemplary modalities is to allow a reliable download or upload of media content, so that the playback user experience is not affected, for example, by network congestion. BRIEF DESCRIPTION OF THE DRAWINGS
    The present invention will be described in more detail below, and with reference to the accompanying figure, of which:
    The 1st figure is a block diagram that illustrates an exemplary IMS IPTV architecture for downloading and uploading media content;
    Figure 1b illustrates an OITF-enabled UE;
    Figures 2a and 2b are signaling diagrams that schematically illustrate exemplary sessions for downloading content initiated by UE, in an IMS IPTV architecture;
    Figures 2c and 2d are signaling diagrams that schematically illustrate exemplary sessions for downloading content initiated by UE, for common IPTV;
    Figure 3 is a flow diagram that schematically illustrates a method for a UE, related to uploading content or downloading content;
    Figure 4 is a flow diagram that schematically illustrates a method for an IPTV control node, relative to uploading content and downloading content;
    Figure 5 is a block diagram that schematically illustrates an exemplary UE; and Figure 6 is a block diagram that schematically illustrates an exemplary IPTV control node. DETAILED DESCRIPTION
    In what follows, the invention will be described in more detail with reference to certain 35 modalities and an accompanying drawing. For the purpose of explanation, and not limitation, specific details are established, such as particular scenarios, techniques, etc., in order to provide a complete understanding of the present invention. However, it is apparent to one skilled in the art that the present invention can be practiced in other embodiments that depart from these specific details.
    In addition, those skilled in the art will appreciate that the functions and means explained hereinafter can be implemented using software operating in conjunction with a programmed microprocessor or general purpose computer, and / or using an application specific integrated circuit (ASIC) . It will also be appreciated that, although the current invention is described primarily in the form of methods and devices, the invention can also be incorporated into a computer program product, as well as a system comprising a computer processor and memory coupled to the computer. 10 processor, in which the memory is encoded with one or more programs that can perform the functions described here.
    A concept of modalities, described below, is to indicate the type of content download or content upload, in an initial request from the User Equipment, in order to define policies for downloading and / or uploading media content, for example, reserve adequate bandwidth.
    According to additional modalities, the type of content download or content upload is indicated by a type attribute attribute in the request, the attribute included in an SDP Offer, contained in the initial request. According to another modality, a bandwidth attribute, proposing a bandwidth, is optionally included in the initial request.
    This transfer type attribute indicates, for example, for IMS and local transport policies, that a session must be defined with specific requirements. For example, if the transfer type attribute indicates a streaming download, and a specific bandwidth is indicated in a bandwidth attribute, a streaming download session must be defined, with a bandwidth. guaranteed, according to the bandwidth indicated in the bandwidth attribute.
    Thus, a bandwidth indicated in the bandwidth attribute indicates a maximum expected bandwidth that is required in order to achieve smooth transmission.
    According to an additional modality, a request comprising a transport type attribute and, optionally, a proposed bandwidth will be rejected, in case the bandwidth that is required for the type of transport indicated in the request is not available on the network. If so, the User Equipment may include a different type of transport attribute in the next request.
    In an IPTV solution based on IMS, according to 35 specimens, QoS (Quality of Service) can be ensured, for example, as defined according to the RACS TISPAN architecture. The signaling required for linear TV and for Video on Demand is specified, for example, in the TISPAN specification and in the OITF specification (Open IPTV Forum).
    The exemplary modalities provide a link between content download and content upload and the above mentioned QoS mechanisms, provided, for example, by IMS / RACS, to ensure that a minimum transmission speed is available to support an uninterrupted view of media content, during download, for example, of the types progressive download, streaming download and adaptive streaming download.
    Thus, in accordance with an embodiment of the invention, the aforementioned transfer type attribute is included in an SDP Offer for downloading content, in order to define policies, specifically, for downloading content. This attribute allows flexibility to control local policies in IMS / RACS, such as, for example, to reserve bandwidth, to add a BGF (Edge Gateway Function) on the path, or to select an appropriate priority on the network. access. RACS policies are defined, for example, according to the standardized SPDF (Service-Based Policy Decision Function).
    Typically, the type of transport for downloading HTTP content is determined by the user device, based on the action of the end user and the configuration of the user device. If the user selects a content to be viewed, and the user's equipment is not configured to store the content, the content will be retrieved from the content server, using a streaming download of the content at the rate of reproduction from the user's equipment. .
    However, if the user's equipment is configured to store the content, the content will be retrieved from the content server that uses progressive download, that is, the content is stored or buffered, on the user's equipment, and reproduced, at the same time.
    In the adaptive streaming download, the end user requests that the content must be available as an adaptive flow, in such a way that the content can be downloaded at different bit rates, according to a special scheme. For example, if the user device detects that the buffer is becoming empty, it can assume that there is a lack of bandwidth for a higher bit rate stream, and switch to a lower download bit rate.
    As described above, downloading conventional HTTP content is a best-effort type of transmission, and the download speed is limited by the available bandwidth. However, in order to achieve a differentiation between the different types of content download and content upload, and transfer type attribute is included in the initial request, from the user equipment, according to the modalities of the invention.
    The different types of content downloads are differentiated with a QoS slightly higher than the best effort QoS, since the best effort QoS has no minimum transmission requirement.
    As stated above, the concepts described are not only applicable for download, but could be used to upload, for example, user generated content. The uploaded content can subsequently be shared with other users, using a download, and therefore will require a consistent transfer.
    Figure 1a is a block diagram that illustrates an exemplary IMS IPTV architecture and the protocols applicable in IMS IPTV, that is, the SIP (Session Initiation Protocol) and HTTP (Hypertext Transfer Protocol), to download media from a content server to a UE, or upload media content to the content server. The architecture comprises an OITF-enabled UE 1, an IMS Gateway 2, an IMS Media Server or Video on Demand pump, as indicated by the IMS / RACS 3 circle in the figure, an IPTV controller 4 and a Content Server 5, comprising a Media Control Function (MCF). The IPTV Controller 4 can comprise, for example, an IPTV Application Platform (IAP), as defined in the Open IPTV Forum.
    Figure 1b is a block diagram that schematically illustrates an OITF 1-enabled User Equipment, comprising functionality for the Declarative Application Environment (DAE), as defined in the Open IPTV forum specification, as well as a local object code, the DAE comprising the UE browser.
    More specifically, in an exemplary unidifusion content download session initiated by UE, an originating UE generates an initial INVITATION Request. The Request Uniform Resource Identifier (URI) contains a URI of downloadable content in a unicast locator, as well as in a TO header, said identifier being retrieved from service selection information. In addition, a SENDER header indicates the user's public user identity.
    An SDP Offer is included in the INVITATION Request, according to the media capabilities and required bandwidth available for the content download session.
    Thus, a typical exemplary SDP Offer, at the media level, can include, for example, the following elements: - A "m =" line for an HTTP download, for example, of the format: m = <media> <port > <transporte> <fmt>:, with the media field having an "application" value, the port field being set to a value of 9, which is the discard port, and the transport field being justified for TCP . In addition, an fmt parameter is included, and set to iptv_http, resulting in "m = application 9 tcp iptv_http". - An "a = configuration" attribute, defined as "active", for example, a = configuration: active. - An "a = connection" attribute, defined as "new", for example, a = connection: new. - A "c =" line, included in the network type, with the value set to IN, the type of address set to IP4 or IP6, and the IP address of the related HTTP channel stream, for example, c = IN IP4 < IPAddress>).
    According to an embodiment of the invention, an SDP Offer line "b =" may optionally contain a bandwidth attribute indicating a proposed bandwidth. If the user has obtained the required bandwidth for this particular content delivery channel during a service selection procedure, the media level bandwidth attribute is set on the line "b =" to this value, for example , b = AS: 15000.
    Consequently, the MCF (Medium Control Function) of the Content Server will receive an SDP Offer, through the IPTV controller, which may contain a transfer type attribute, as well as a bandwidth attribute indicating a proposed bandwidth ( on a "b =" line). The Content Server MCF will assist the IPTV controller in preparing content for download or upload, and will copy a transfer type attribute received in an SDP Response, which is forwarded to the IPTV controller.
    Additionally, according to exemplary modalities of the invention, as described above, the type of content download is indicated in the initial INVITATION request, for example, by transferring a type attribute contained in the SDP Offer, such as an "fmtp attribute. : iptv_http transfer-type ". According to a first embodiment of the invention, the values that are applicable for the transfer type attribute are "progressive", "continuous flow" and "adaptive".
    The "progressive" content download type indicates content that is viewed during download, and the content is stored or buffered in the UE, requiring comparatively large bandwidth.
    The "streaming" content download type, for example, HTTP streaming, indicates content that is viewed without storing, or with a limited buffer in the UE, similar to RTSP streaming.
    The type of "adaptive" content download, for example, adaptive HTTP streaming, indicates content that can be viewed in different bandwidth and with different quality.
    The "b =" line is an optional bandwidth attribute, and indicates the bandwidth for the best quality streaming.
    According to additional exemplary modalities, several other transfer type attribute values could be used to indicate other proprietary types of content downloads, for example, a = fmtp: iptv__http transfer-type = <transfer-type> .
    Figures 2a and 2b show a signaling diagram that illustrates an exemplary signaling sequence for User Equipment 1, which acts as a client terminal in an IMS IPTV architecture. The figures illustrate the User Equipment downloading media content from a Content Server 5, the download involving a bandwidth reserve, according to the modalities of this invention. The figures also illustrate the logical units that can be involved.
    The UE 1 (OITF) box indicates an OITF-enabled User Equipment, comprising functionality for the Declarative Application Environment (DAE), as defined in the Open IPTV Forum, as well as a local object code (LOC). In addition, the IG 2 box corresponds to an IMS Gateway, the IMS / RACS 3 box corresponds to an IMS Media Server or a Video on Demand pump, and the IPTV Controller 4 includes an IPTV Application Platform (IAP) . Content Server 5 comprises a Media Controller Function (MCF).
    In signal S11, in figure 2a, UE 1 initiates a download session, which is created in signal S12. At the S13 signal, a SIP INVITATION is forwarded from the IMS 2 Gateway to the IMS 3 Media Server, and, at the S15 signal, sent to the IPTV Controller 4, the SIP INVITATION, including an Offer of Offer SDP (Session Description Protocol), and the content is prepared to download, in step 16, by the IPTV Controller 4 and by the Content Server 5.
    In the preceding step 14, the policies for downloading are checked and enforced by IMS / RACS, and a bandwidth reservation can be made. This involves that the network topology in the access network is checked by the RACS in order to determine whether the bandwidth required by the type of transport indicated in the SIP INVITATION SDP Offer is available. If so, the bandwidth is reserved, and the SIP INVITATION will be forwarded to the IPTV Controller, at signal S15. However, if the required bandwidth is not available, the SIP INVITATION will be rejected, and not forwarded to the IPTV Controller. When the IPTV Controller receives a non-rejected SIP INVITATION, the content will be prepared for download, in the above mentioned step 16.
    Then, at signal S17, the IPTV Controller will respond with an SDP response, as well as with the URL for the session, which is forwarded to the IMS Gateway, at signal S19, and the bandwidth reservation is confirmed, in previous step 18. Subsequently, the session is created, at signal S20. The UE uses the URL of the received session to download the content from Content Server 5, on signals S21, S22 and S23 in figure 2b. On signals S24 - S30, the download session is ended, including a release of network resources, in step 26, and, eventually, on signals S31 and S32, the downloaded content is played.
    The above described figures 2a and 2b illustrate a download session. However, a similar signaling procedure can be used for an upload session.
    Other exemplary modalities are directed to simple IPTV on a non-IMS network, using other protocols, for example, SOAP (Simple Object Access Protocol) or DIAMETER protocol, instead of SIP.
    Thus, Figures 2c and 2d illustrate exemplary signaling diagrams for a simple IPTV architecture, without an IMS Gateway, using SOAP, and having a RACS 3 interface for the IPTV Controller 4. In signal S110 in figure 2c, UE 1 starts a download session, which is created on signal S120. At signal S130, the IPTV controller queries a reserve SOAP bandwidth for the RACS interface. If the reservation is confirmed, in step 140, a SOAP response is sent to the IPTV controller, at signal S150. In step 160, the IPTV controller prepares the content for download, and the session is created, as a sign of S170.
    The UE uses a received session URL to download content from Content Server 5, on signals S180, S190 and S200 in figure 2d. On the S210 - S260 signals, the download session is ended, including a release of network resources, in step 230, and, eventually, on the S270 and S280 signals, the downloaded content is played.
    Figure 3 is a flow diagram that schematically illustrates a method for a User Equipment to define a policy for uploading or downloading media content, according to the modalities of the invention. In step 35, the UE generates a request indicating the type of content download or content upload, and transmits the request to the IPTV control node, in step 36. According to another modality, the policy is a band reserve , and the type is indicated by a transport type attribute, included in an SDP Offer from the initial request. According to yet another modality, the transfer type attribute has one of the values "progressive", "continuous flow" or "adaptive", as defined above. Steps 35 and 36 in figure 3, when directed to download, basically correspond to signals S11 - S15 in figure 2a.
    Figure 4 is a flow diagram that schematically illustrates a method, for an IPTV Control Node, of defining a policy for uploading or downloading media content, according to the modalities of the invention. In step 41, the IPTV Controller node receives a request from the UE, the request indicating the type of content download or content upload. In step 42, the IPTV control node copies the type of download or upload in an SDP response, through the MCF (Media Control Function) of the content server. According to another modality, the policy is a bandwidth reserve, which is defined according to an expected transmission speed, based on the type of download or content upload, as indicated by the transport type attribute, included in an SDP Offer of the initial request, received from the UE in the aforementioned step 41. According to yet another modality, the value of the transfer type attribute is, for example, progressive, continuous or adaptive.
    Figure 5 is a block diagram illustrating User Equipment 1, according to the modalities of the invention. The UE 1 is an example of an OITF-enabled mobile phone, a PC or a TV, comprising a suitable user interface, and is provided with processing circuits and appropriate software, for example, corresponding to a Declarative Application Environment (DAE ), as defined in the Open IPTV Forum, as well as a local object code. The software is further configured to execute the method according to the modalities of the present invention. The UE is also provided with a conventional communication device 51, which comprises a transmitter, receiver and processing circuits 52, in order to communicate with an IPTV Controller, for example, through an IMS Gateway and a Media Server of IMS. According to an exemplary modality, the UE generates and transmits a request, including an SDP Offer indicating the type of content download and / or content upload.
    Figure 6 is a block diagram illustrating an exemplary IPTV 4 control node, comprising an IPTV Application Platform (IAP). The IPTV control node is additionally provided with a communication device 61, which comprises a transmitter, receiver and processing circuits 62, and by means of the communication device and other suitable hardware and software, the IPTV control node is configured to receive a request that indicates the type of content download or content upload from a UE, for example, in a transfer type attribute, included in an SDP Offer. According to another modality, the communication device is configured to copy the transfer type attribute to an SDP response, through the MCF (Media Control Function) contained in the content server. According to a preferred modality, the policy is a bandwidth reserve, and the IPTV control node is willing to set the session with a bandwidth, according to an expected transmission speed, based on a type attribute. transfer received.
    The entities and units described above, with reference to figures 5 and 6, are logical units, which do not necessarily correspond to separate physical units.
    Thus, according to modalities of a method for a User Equipment, directed to download media content, User Equipment 1 defines a policy to download IPTV content from a server, by generating a request comprising an indication of the type of content download, and transmitting the request to an IPTV 4 controller.
    According to exemplary modalities, the policy is a reserve of bandwidth, and the type of content download is indicated by a standardized transfer type attribute, for example, progressive, which denotes a progressive download, continuous flow, the which denotes a streaming download, or adaptive, which denotes an adaptive streaming download.
    According to exemplary modalities, IPTV is based on IMS, and the indication of the type of content download is contained in an SDP Offer, included in the request. In addition, the SDP Offering may comprise a bandwidth attribute indicating a proposed bandwidth.
    According to yet another modality, the User Equipment will receive a rejection of the request if the required bandwidth for the type of transport indicated by the transport type attribute is not available, and the User Equipment can generate a request comprising an attribute different type of transport after receiving the rejection.
    According to modalities of a similar method for a User Equipment directed to upload, User Equipment 1 defines a policy to upload IPTV content to a server, by generating a request that includes an indication of the type of upload. content, and transmit the request to an IPTV 4 controller.
    According to exemplary modalities, the policy is a bandwidth reservation, which is defined according to an expected transmission speed, and the type of content upload is indicated by a standardized transfer type attribute, for example, "progressive" , "streaming" or "adaptive", attributes that denote a progressive upload, a streaming upload, and an adaptive streaming upload, respectively.
    According to other exemplary modalities, IPTV is based on IMS, and the indication of the type of content upload is contained in an SDP Offer, included in the request. In addition, the SDP Offering may comprise a bandwidth attribute that indicates a proposed bandwidth.
    According to yet another modality, the User Equipment will receive a rejection of the request if the necessary bandwidth for the type of transport indicated by the transport type attribute is not available, and the User Equipment can generate a request that comprises a different transport type attribute after receiving the rejection.
    A User Equipment communicates with an IPTV control node in order to define the upload and download policies. According to modalities of a method for an IPTV control node 4, directed to download, the IPTV control node 4 defines a policy to download IPTV content from the content server 5 to a User Equipment 1, the IPTV controller receiving a request from the User Equipment, the request comprising an indication of the download type content.
    According to exemplary modalities, the policy is a bandwidth reservation, which is defined by the IPTV 4 control node, according to an expected transmission speed, based on the indication received of the type of content download. Said type of content download is indicated by a standardized transfer type attribute, for example, "progressive", "streaming" or "adaptive", the attributes denoting progressive upload, streaming upload and an adaptive streaming upload , respectively.
    According to yet another modality, IPTV is based on IMS, and the indication of the type of content download is contained in an SDP Offer, included in the request received from the UE. In addition, the SDP Offering may comprise a bandwidth attribute, indicating a proposed bandwidth, and the indication of the type of content download can be copied to an SDP response.
    According to modalities of a method for an IPTV control node, directed to upload, the IPTV control node 4 defines a policy to upload IPTV content from UE 1 to a content server 5, the IPTV controller receiving a request from the User Equipment, the request comprising an indication of the type of content upload.
    According to exemplary modalities, the policy is a reserve of bandwidth, which is defined according to an expected transmission speed, based on the indication received of the type of content upload. Said content upload type is indicated by a standardized transfer type attribute, for example, "progressive", "streaming" or "adaptive", the attributes denoting a progressive upload, a streaming upload and an upload adaptive continuous flow, respectively.
    According to additional exemplary modalities, IPTV is based on IMS, and the indication of the type of content upload is contained in an SDP Offer, included in the request. In addition, the SDP Offer comprises a bandwidth attribute, indicating a proposed bandwidth, the indication of the type of content upload is copied to an SDP response.
    According to modalities of a User Equipment 1, the UE is willing to define a policy to download IPTV content from a content server 5, the User Equipment comprising a communication device 61, provided with communication circuits processing 62, and is configured to generate a request that comprises an indication of the type of content download, and to transmit the request to an IPTV control node 4.
    In addition, according to the modalities of a User Equipment, User Equipment 1 is arranged to define a policy for uploading IPTV content to a server 5, the User Equipment comprising a communication device 61, provided with circuits processing 62, and is configured to generate a request that comprises an indication of the type of content upload, and to transmit the request to an IPTV control node.
    Thus, a User Equipment, according to the invention, is preferably disposed to define policies, both for downloading and uploading, but may, alternatively, be disposed to define policies for, or downloading, or uploading.
    In accordance with additional exemplary modalities of said User Equipment, the policy is a reservation of bandwidth, and the type of content download and / or the type of content upload is indicated by a standardized transfer type attribute, for example. example, "progressive", "streaming" or "adaptive", attributes denoting a progressive upload, a streaming upload, and an adaptive streaming upload, respectively.
    According to yet another exemplary modality, IPTV is based on IMS, and the indication of the transfer type attribute is contained in an SDP Offer, included in the request. In addition, the SDP Offering additionally comprises a proposed bandwidth, and the EU is enabled for OITF.
    As with the exemplary methods described above, a User Equipment is configured to communicate with an IPTV control node, to define policies for uploading and downloading. According to the modalities of an IPTV control node 4, the IPTV control node 4 is arranged to define a policy to download IPTV content from a content server 5 to a User Equipment 1, the node IPTV controller comprising a communication device 51, provided with processing circuitry 52, and is configured to receive a request from the User Equipment, the request comprising an indication of the type of content download.
    Additionally, according to the modalities of an IPTV control node 4, the IPTV control node is willing to define a policy for uploading IPTV content from a content server 5 to a User Equipment 1, the said node comprising a communication device 51, provided with processing circuitry 52, and is configured to receive a request from the User Equipment, the request comprising an indication of the type of content upload.
    According to another exemplary modality, the policy is a bandwidth reservation, and the IPTV control node is willing to set the bandwidth reservation according to an expected transmission speed, based on the indication of the type of download received. content and / or content upload. The type of content download and / or type of content upload is indicated by a standardized transfer type attribute, for example, "progressive", "streaming" or "adaptive", the attributes denoting a progressive upload, an upload streaming and progressive streaming upload, respectively.
    According to yet another exemplary modality, IPTV is based on IMS, and the transfer type attribute is contained in an SDP Offer, included in the request, the SDP Offer additionally comprising a proposed bandwidth.
    The IPTV control node can be additionally arranged to copy an indication received of the type of content upload and / or the type of content download in an SDP response, via the content server's MCF.
    Thus, an IPTV control node, according to the modalities, is preferably arranged to define policies for both downloading and uploading, but may, alternatively, be willing to define policies for either downloading or uploading.
    As further described, in connection with figures 2c and 2d, exemplary modalities are applicable to a non-IMS network, for example, in the so-called simple or traditional IPTV. However, in the case of a non-IMS network, a separate protocol, similar to SIP, is necessary in order to create a session, with the backend to allocate and shift the bandwidth, for example, the SOAP or DIAMETER protocols. Alternatively, a new HTTP header could be added, with a proposed bandwidth, and the type of transfer included, or the information could be encapsulated in an HTTP request URI, without the need for any separate protocol.
    In addition, the aforementioned and described embodiments are given as examples only and should not be limiting to the present invention. Other solutions, uses, objectives and functions within the scope of the invention, as claimed in the accompanying patent claims, should be apparent to the person skilled in the art.
    ABBREVIATIONS OITF = OPEN IPTV SDP Forum = MCF Session Descriptive Protocol = IAP Media Control Function = IPTV Application Platform RACS = Admission Resource Control Subsystem SPDF = DAE Service-Based Policy Decision Function = Application Environment Declarative QoS = Quality of Service URI = Uniform Resource Identifier SOAP = Simple Object Access Protocol HTTP = Hypertext Transfer Protocol SIP = Session Initiation Protocol
    权利要求:
    Claims (16)
    [0001]
    1. Method, for a User Equipment (1), of defining a policy to download content from Internet Protocol Television, IPTV, from a Content Server (5), or a policy to upload content IPTV to a Content Service (5), characterized by the fact that it comprises: - generating (31) a request comprising an indication of the type of transfer of content download or content upload and a bandwidth attribute proposing a width band, in which the transfer type is indicated by a transfer type attribute that has one of the progressive, continuous or adaptive values; and - transmitting (32) the request to an IPTV control node (4).
    [0002]
    2. Method, according to claim 1, characterized by the fact that the policy is a reserve of bandwidth.
    [0003]
    3. Method, according to claim 1 or 2, characterized by the fact that IPTV is based on Internet Protocol Multimedia Subsystem, IMS, and the transfer type attribute is contained in a Session Descriptive Protocol Offer, SDP, included in the request.
    [0004]
    4. Method, according to claim 3, characterized by the fact that the SDP Offer also comprises the bandwidth value, corresponding to a proposed bandwidth.
    [0005]
    5. Method according to any one of claims 2 to 4, characterized by the fact that it also comprises the User Equipment (1) receiving a rejection of the request, if the bandwidth required by the transport type attribute is not available .
    [0006]
    6. Method, according to claim 5, characterized by the fact that it comprises generating a request containing an attribute of different type of transport, if a rejection is received.
    [0007]
    7. Method, for an Internet Protocol Television control node (4), IPTV, to define a policy to download IPTV content from a Content Server (5) to a User Equipment, UE, (1), or upload IPTV content to a Content Server (5) from User Equipment (1), characterized by the fact that it comprises: - receiving (41) a request from User Equipment (1), the request comprising an indication of the type of content download or content upload and a bandwidth attribute proposing a bandwidth, where the type of content download or content upload transfer is indicated by a transfer type attribute that has one of the progressive, continuous or adaptive values.
    [0008]
    8. Method, according to claim 7, characterized by the fact that the policy is a bandwidth reserve, which is defined according to an expected transmission speed, based on the type of content download or content upload .
    [0009]
    9. Method, according to claim 8, characterized by the fact that it also comprises: - copying (42) the transfer type attribute from a Session Descriptive Protocol Offer, SDP, included in the request, in a response SDP, included in a response, through a Media Control Function, MCF, from the Content Server (5).
    [0010]
    10. User Equipment (1), willing to define a policy for downloading Internet Protocol Television, IPTV content from a Content Server (5), and / or uploading IPTV content to a Content Server (5), the User Equipment (1), comprising a communication device (51), provided with processing circuits (52), characterized by the fact that it is configured to: - generate a request comprising an indication of the type transfer of content download and / or upload of content and a bandwidth attribute proposing a bandwidth, in which the type of transfer is indicated by a transfer type attribute that has one of the values progressive, streaming or adaptive; and - transmit the request to an IPTV control node (4).
    [0011]
    11. User Equipment (1), according to claim 10, characterized by the fact that the policy is a reserve of bandwidth.
    [0012]
    12. User Equipment (1), according to claim 10 or 11, characterized by the fact that IPTV is based on Internet Protocol Multimedia Subsystem, IMS, and the transfer type attribute is contained in an Offer of Session Description Protocol, SDP, included in the request.
    [0013]
    13. User Equipment (1), according to claim 12, characterized by the fact that the SDP Offering still comprises a proposed bandwidth.
    [0014]
    14. Internet Protocol Television control node (4), IPTV, willing to define a policy to download IPTV content from a Content Server (5) to a User Equipment, EU, (1) , and / or to upload IPTV content to a Content Server (5) from User Equipment (1), the IPTV control node (4) comprising a communication device (61) provided with circuits processing (62), characterized by the fact that it is configured to: - receive a request from the User Equipment (1), the request comprising an indication of the type of transfer of content download or content upload and a width attribute bandwidth including a bandwidth value for the indicated transfer type, where the transfer type of content download or content upload is indicated by a transfer type attribute that has one of the values progressive, streaming or adaptive.
    [0015]
    15. IPTV control node (4), according to claim 14, characterized by the fact that the policy is bandwidth reserve, which is defined according to an expected transmission speed, based on the type of download content or content upload.
    [0016]
    16. IPTV control node (4), according to claim 14, characterized by the fact that it is still configured to copy the transfer type attribute from a Session Descriptive Protocol Offer, SDP, included in the request in a Descriptive Session Protocol (SDP) response, included in a response, through a Media Control Function, MCF, from the Content Server (5).
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112012013927B1|2021-02-02|methods of defining policies for downloading content and uploading content to user equipment and a related control node, user equipment and control node
    US10958699B2|2021-03-23|Session control for media stream transmission
    JP6231583B2|2017-11-15|Transport diversity and time shift buffer support for media streaming over the network
    US20160173581A1|2016-06-16|Method and Apparatus for Providing Relevant Service Levels
    WO2011032431A1|2011-03-24|Method and apparatus for transmitting hyper text transport protocol | media
    KR20150083793A|2015-07-20|Method for downloading, at a client terminal, an upcoming sequence of segments of a multimedia content, and corresponding terminal
    BR122016022895A2|2019-08-27|dynamic adaptive streaming methods by hypertext transfer protocol
    JP5042370B2|2012-10-03|Method and apparatus for acquiring media description information of IPTV service
    KR20160106701A|2016-09-12|Method for obtaining network information by a client terminal configured for receiving a multimedia content divided into segments
    WO2014169588A1|2014-10-23|Method and apparatus for selecting playable code rate content
    US20110295943A1|2011-12-01|Data processing system and method
    EP2448260B1|2015-09-16|Content upload method and content delivery function entity
    CN102047681A|2011-05-04|Method and apparatus for using internet protocol television service based on application received in multicast session
    WO2010028601A1|2010-03-18|Method, system and equipment for transmitting media contents by means of files
    EP2564596A1|2013-03-06|Method and arrangement for playing out a media object
    KR102212973B1|2021-02-04|Method for providing a content part of a multimedia content to a client terminal, corresponding cache
    BR102019026713A2|2020-06-23|METHOD, SYSTEM AND DEVICES FOR IMPROVED DISTRIBUTION OF MULTIMEDIA CONTENT
    WO2010022603A1|2010-03-04|A method, a system and an apparatus for attaching to the peer to peer network and obtaining iptv contents
    同族专利:
    公开号 | 公开日
    JP2015029327A|2015-02-12|
    BR112012013927A2|2016-04-26|
    MX2012006537A|2012-07-17|
    EP2510670A4|2017-10-25|
    CN102652421B|2015-06-03|
    CN102652421A|2012-08-29|
    SG10201407882UA|2015-01-29|
    US9215483B2|2015-12-15|
    EP2510670A1|2012-10-17|
    US20110138431A1|2011-06-09|
    HK1170863A1|2013-03-08|
    WO2011071439A1|2011-06-16|
    JP2013513992A|2013-04-22|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    JP2004153778A|2002-09-03|2004-05-27|Ntt Docomo Inc|Apparatus, method, and program for transmission/reception control|
    US8099756B2|2005-11-10|2012-01-17|Versteeg William C|Channel changes between services with differing bandwidth in a switched digital video system|
    KR100817374B1|2006-07-24|2008-03-27|하나로미디어|System and method for the continuous display of grouped and independent multiple contents|
    US20080152316A1|2006-12-21|2008-06-26|Nortel Networks Limited|Remote control of media content delivery to a digital media recorder|
    KR101316743B1|2007-03-13|2013-10-08|삼성전자주식회사|Method for providing metadata on parts of video image, method for managing the provided metadata and apparatus using the methods|
    US20080228912A1|2007-03-16|2008-09-18|Ramakrishna Vedantham|Enhanced Quality Reporting for Transmission Sessions|
    CN101287091B|2007-04-10|2010-11-24|华为技术有限公司|System, device and method for implementing television service based on Internet protocol|
    EP2157744A4|2007-08-21|2012-08-22|Huawei Tech Co Ltd|Method and system for controlling the authorization of service resource|
    JP2009059160A|2007-08-31|2009-03-19|Sony Corp|Server device, network system, content discovery notification method and computer program|
    US8209728B2|2007-08-31|2012-06-26|At&T Intellectual Property I, L.P.|System and method of delivering video content|
    JP5018560B2|2007-09-03|2012-09-05|ソニー株式会社|IPTV client terminal, SIP-INVITE message generation method, IPTV system, IPTV session control method, computer program, IPTV client system, and session management apparatus|
    WO2009051531A1|2007-10-16|2009-04-23|Telefonaktiebolaget Lm Ericsson |Method and apparatus for improving the efficiency of resource utilisation in a communications system|
    JP2009159087A|2007-12-25|2009-07-16|Sharp Corp|Access control device|
    US20090178091A1|2008-01-08|2009-07-09|Hiroki Miyamoto|Contents distribution method and receiving device|
    JP5150459B2|2008-01-08|2013-02-20|株式会社日立製作所|Content distribution method and receiving apparatus|
    EP2091203A1|2008-02-12|2009-08-19|Koninklijke KPN N.V.|Method and system for transmitting a multimedia stream|
    US7852849B2|2008-03-04|2010-12-14|Bridgewater Systems Corp.|Providing dynamic quality of service for virtual private networks|
    US9131278B2|2009-11-23|2015-09-08|At&T Intellectual Property I, Lp|System and method for layered delivery of media content quality|US10410222B2|2009-07-23|2019-09-10|DISH Technologies L.L.C.|Messaging service for providing updates for multimedia content of a live event delivered over the internet|
    US9049484B2|2011-12-06|2015-06-02|Echostar Technologies L.L.C.|Efficient assignment of program copies in a network digital video recorder|
    EP2792123B1|2011-12-06|2017-09-27|Echostar Technologies L.L.C.|Remote storage digital video recorder and related operating methods|
    US20130305274A1|2012-05-14|2013-11-14|Telefonaktiebolaget L M Ericsson |Over the top content access|
    US8862090B2|2012-05-21|2014-10-14|At&T Intellectual Property I, L.P.|Intelligent long term evolution circuit switched fallback management|
    US9444862B2|2012-09-29|2016-09-13|Intel Corporation|Dynamic media content output for mobile devices|
    KR102020363B1|2012-10-31|2019-09-10|삼성전자 주식회사|Method and apparatus for transmitting and receiving media segment using adaptive streaming|
    WO2014106206A1|2012-12-28|2014-07-03|DISH Digital L.L.C.|Adaptive multicast delivery of media streams|
    US10051025B2|2012-12-31|2018-08-14|DISH Technologies L.L.C.|Method and apparatus for estimating packet loss|
    US10104141B2|2012-12-31|2018-10-16|DISH Technologies L.L.C.|Methods and apparatus for proactive multi-path routing|
    US10708319B2|2012-12-31|2020-07-07|Dish Technologies Llc|Methods and apparatus for providing social viewing of media content|
    JP6394591B2|2013-04-05|2018-09-26|ソニー株式会社|Control device, control method, computer program, and video transmission system|
    AU2014278788B2|2013-06-14|2019-03-14|Trek TechnologyPte Ltd|System and method for uploading, showcasing and selling news footage|
    CN103685301A|2013-12-24|2014-03-26|乐视网信息技术（北京）股份有限公司|Method and system for adaptively processing connection content delivery network|
    EP3113468B1|2014-02-28|2020-04-08|Panasonic Intellectual Property Corporation of America|Voice communication terminal, intermediate node, processing device, connection method, and program|
    CN104469426B|2014-12-01|2017-12-22|中国联合网络通信集团有限公司|A kind of dispatching method and system of multimedia-on-demand content|
    WO2017063677A1|2015-10-13|2017-04-20|Telefonaktiebolaget Lm Ericsson |Adaptive precision for reporting consumption of streamed content|
    CA3010043C|2015-12-29|2020-10-20|DISH Technologies L.L.C.|Dynamic content delivery routing and related methods and systems|
    法律状态:
    2019-01-08| B06F| Objections, documents and/or translations needed after an examination request according art. 34 industrial property law|
    2019-12-24| B15K| Others concerning applications: alteration of classification|Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04L 29/06 , H04H 60/85 , H04N 7/173 Ipc: H04L 29/06 (1990.01), H04N 21/2385 (2011.01), H04N |
    2019-12-24| B06U| Preliminary requirement: requests with searches performed by other patent offices: suspension of the patent application procedure|
    2021-01-19| B09A| Decision: intention to grant|
    2021-02-02| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 02/02/2021, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    US26798909P| true| 2009-12-09|2009-12-09|
    US61/267,989|2009-12-09|
    US32124910P| true| 2010-04-06|2010-04-06|
    US61/321,249|2010-04-06|
    PCT/SE2010/051317|WO2011071439A1|2009-12-09|2010-11-30|Policies for content downloading and content uploading|
    [返回顶部]